剛開始學寫程式時,我也把大部分注意力放在語法上。變數怎麼宣告?迴圈怎麼寫?框架又該選哪一套?這些當然都要學,但真正開始做專案後,我更常碰到另一種狀況:IDE 已經打開了,第一行卻不知道該寫什麼。
假設客戶說:「幫我做一個待辦清單。」聽起來不難,真的動手後,問題才一個個冒出來。任務需要哪些欄位?完成後要刪除,還是保留紀錄?空白名稱算不算合法?這些細節還沒問清楚就開始寫 Code,很可能做到一半才發現,雙方想像的「完成」根本不是同一件事。
所以在寫程式之前,得先把模糊的需求整理成能理解、能執行,也能驗證的解法。這就是運算思維在處理的事。
運算思維(Computational Thinking)是運用電腦科學的觀念來分析問題、設計系統與規劃解法。Jeannette M. Wing 教授在 2006 年發表〈Computational Thinking〉,主張這是每個人都能學習的基本能力,不只屬於電腦科學家。[1]
Wing 也提到,像電腦科學家一樣思考,範圍其實比寫程式更廣。程式設計是把解法轉成電腦可以執行的指令;運算思維發生得更早,先釐清「問題是什麼」和「打算怎麼解」。拿紙筆就能開始,不必急著開啟 IDE。

圖 1:運算思維特徵
| 項目 | 運算思維 | 程式設計 |
|---|---|---|
| 處理重點 | 整理問題與規劃解法 | 用程式語言實作解法 |
| 是否一定需要電腦 | 不一定,可先用紙筆分析 | 通常需要開發工具與執行環境 |
| 產出 | 模型、規則、流程與驗收條件 | 可執行的程式 |
| 適用範圍 | 軟體開發、科學研究與日常決策 | 軟體系統及自動化工作 |
ISTE 將運算思維整理成四個常見的入門支柱:問題分解、模式識別、抽象化與演算法。[2] 臺灣的科技領域課綱也把邏輯與運算思維列入要培養的高層次思考能力。[3] 這四項不是跑完一次就結束的固定流程,比較像一組可以反覆拿來用的工具。接下來,就用「待辦清單」實際走一遍。

圖 2:同一個待辦清單需求,會在四種思考工具之間反覆整理與修正
「做一個待辦清單」還不能直接拿來開發。可以先拆成新增任務、查看清單、標示完成與刪除任務,再逐一確認每項功能的輸入、輸出,以及可能失敗的情況。
以新增任務為例,至少要問:任務名稱可不可以空白?新增成功後要立刻顯示嗎?名稱太長時怎麼處理?每個小問題都能單獨討論、實作和測試,這樣的分解才真的有用。如果拆完還是不知道從哪裡開始,通常表示問題拆得還不夠小。
新增、完成和刪除看起來是不同功能,但仔細看,它們的處理方式很相似:接收使用者操作、檢查資料、更新任務,最後把結果顯示在畫面上。每筆任務也都有共同欄位,例如名稱與完成狀態。
看出這些重複模式後,就能考慮共用資料結構或驗證邏輯,不必每個功能都重寫一套。不過,相似不等於相同。刪除任務可能需要再次確認,標示完成就不一定需要;硬把兩種流程湊在一起,程式反而更難讀。
談到待辦清單,很容易馬上想到帳號登入、到期提醒、標籤、排序和跨裝置同步。每一項都很合理,但第一版全部塞進去,需求很快就會失控。
抽象化是在目前的情境裡,留下真正會影響解法的資訊,暫時放下還用不到的細節。假設第一版只想驗證基本流程,任務可以先簡化成:
任務 = 名稱 + 是否完成
提醒時間和使用者帳號先不處理,同時把這次的開發範圍記清楚。等下一版真的要做提醒功能,再把時間加進資料模型。
範圍確定後,我們可以先用自然語言描述「新增任務」的流程:
1. 取得使用者輸入的任務名稱
2. 移除名稱前後的空白
3. 如果名稱為空,顯示錯誤並停止
4. 建立一筆尚未完成的任務
5. 將任務加入清單
6. 顯示更新後的清單
這就是演算法設計的基本精神:把解法寫成順序清楚、可以重複執行,而且能檢查結果的步驟。流程列完了,還要換幾種情況試試看,例如一般名稱能不能新增、只輸入空白會怎樣,或連續新增兩筆時,原本的資料會不會消失。測出問題,就回頭調整前面的分解、資料模型或流程。
把四個支柱排成順序,只是為了方便說明。實際工作很少一路走到底,通常都得來回修正。你可能設計刪除流程時,才發現任務需要唯一編號;也可能寫測試時,才想到刪除應該改成可以復原的封存。
生成式 AI 可以幫忙找出遺漏的需求、比較不同流程,也能根據驗收條件產生測試案例。不過,如果只丟一句「幫我做待辦清單」,它也只能自己猜細節。問題要做到哪裡、資料怎麼取捨、結果如何驗證,最後還是得由開發者決定。
下次接到需求時,不妨先問自己:輸入是什麼?預期輸出是什麼?哪些情況會失敗?目前的步驟,能不能讓另一個人照著重現?把這些事想清楚再開始寫 Code,通常能少繞幾次路。